Over the past generation, businesses have been undergoing major changes in the ways that they conduct their business. One of the most dramatic trends has been in the reduction of employees, functions and facilities through the out-sourcing of virtually anything that can be out-sourced. This has made many businesses leaner and more competitive with significantly reduced staffs and facilities to be maintained. However, along with these advantages has come a loss in control of the performance of many functions, as well as a diminished ability to control the quality of the resulting products.
This diminished control on the part of the business developer of products has become most pronounced in the supplying of software or computer program products. Suppliers of software present major quality assurance problems to developers of computer systems who are potential purchasers. Over its first forty years, prior to the 1980's, the software development environment was one in which an individual or a small dedicated group willing to put in long hard hours could create “elegant” software or “killer applications” directed to and effective in one or more of the limited computer system environments existing at the time. Unlike hardware or industrial product development, the development of software did not require substantial investment in capital equipment and resources. Consequently, in the software product field, the business and consumer marketplace to which the software is directed has traditionally expected short development cycles from the time that a computer need and demand becomes apparent to the time that a commercial software product fulfilling the need becomes available.
Unfortunately, with the explosion of computer usage and the resulting wide diversity of computer systems that must be supported by, or at least not incompatible with, each newly developed computer software product, the development cycles have become very complex. Even when the software product development is an upgrade of an existing product, every addition, subtraction or modification of the program could have an insignificant or a profound effect on another operating system or application program that must be supported.
During the evolution of the software industries over the past two decades it has been evident that developing software will be combined in new, often unforeseen, ways; and, thus, there is an increased likelihood that the individual developments will drive system programs that must be supported into inoperable states for certain purposes or under certain conditions. This changed development environment has caused many traditional and responsible software development houses to take the time and make the effort to resolve all potential incompatibilities with all existing and standard software before the new developed software products were commercially released. Unfortunately, the computer industry landscape is littered with the “corpses” of such responsible longer development cycle software houses that lost out to newer software product entrepreneurs that rushed to the market, or to buyers with products that were less than complete.
Whether the customer of a software supplier is acquiring the software for specific internal needs or to be incorporated into broader products to be marketed by the customer, dysfunctional software products from even one supplier can derail an entire enterprise with profound marketing or economic effects. Accordingly, processes and systems do exist for assessing the quality levels of software suppliers. Copending U.S. patent application Ser. No. 09/710,920, Timothy A. Dietz et al., Business Method for Performing Qualifications of Software and Software Development Organizations, filed Nov. 9, 2000, and assigned to the same assignee of the present invention, provides an effective method for accessing the quality of software suppliers.
Unfortunately, because of the extensive need for software suppliers due to extensive business out-sourcing, together with the high turnover in reliable software suppliers, it may often be difficult for system developers to get software suppliers of known reliability to provide for their software requirements on the developer's schedules. Consequently, it may often be the case that the software supplier may be less than the best available supplier or may be of relatively unknown quality.
It is not enough that the software supplier provide the customer with financial guarantees as to quality and schedules. The suppliers often will not have the resources to make up for the substantial losses that may result from defective software.
In view of the above circumstances, purchasers from software suppliers have been in need of processes for assuring or at least factoring the qualifications and reliability of such suppliers into their profitability pictures. Accordingly, the software industry has, over the past decade, been developing standards by which suppliers of software products may be evaluated. The Carnegie Mellon University has been foremost in such developmental activities through its Software Engineering Institute (SEI) and has generated a Capability Maturity Model (CMM)™, which is now an industry standard for evaluating software suppliers. A basic description of this industry standard is described in the article, Capability Maturity Model, Version 1.1, authored by Mark C. Paulk et al. of Carnegie Mellon, appearing in IEEE Software, Vol. 10, No. 4, July 1993, pp. 18-27. The SEI-SW CMM rates software product supplier based upon five levels of maturity respectively accorded to the software suppliers based upon the development of the software organization. For example, at the lowest level, i.e. immature organization, there is no objective basis for judging product quality or for solving software product or process problems. Therefore, product quality is difficult to predict. Activities intended to enhance quality, such as phase reviews and testing, are often curtailed or eliminated when projects fall behind schedule. The immature (CMM-level 1) organization is reactionary. Thus, managers are continually focused on solving immediate crises. Schedules and budgets are routinely exceeded because they are not based on realistic estimates. Faced with deadlines, software product functionality and quality are often compromised to meet the schedule. Conversely, at the highest maturity level (CMM-level 5), for example, the organization has the organization-wide ability for managing software development and maintenance processes. The software process is accurately communicated to all of the staff and work activities are carried out according to the planned process. The processes mandated are consistently followed in getting the work done. Roles and responsibilities within the defined processes are clear throughout projects and across the organization. Managers monitor the quality of the software products. There is an objective quantitative basis for judging quality and analyzing problems in products or processes. Schedules and budgets are based on historical performance and are realistic. The expected results for cost, schedule, functionality and quality of the product are usually achieved. In general, a disciplined process is consistently followed because all of the participants understand and the necessary infrastructure exists to support the process. According to the SEI CMM, there are five standard levels of software process maturity that may be accorded to a software supplier: 1) initial level having the immature conditions described above; 2) processes are repeatable and disciplined; 3) standard well defined and consistent processing (this is defined as the industry standard or ideal level of maturity that serves as the benchmark against which the other levels are measured—a software supplier at this level typically produces software that has a defect density no greater than 1 defect/KSLOC (no greater than one defect per thousand lines of code); 4) Managed level software processes are quantifiable and consistently predictable, as well as being operable within well defined limits; and 5) the ultimate maturity level described above.